home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000078_yackd@texas.et.byu.edu_Mon Oct 25 15:08 MDT 1993.msg < prev    next >
Internet Message Format  |  1994-10-30  |  4KB
  1. Received: from yvax.byu.edu by maine.et.byu.edu; Mon, 25 Oct 93 15:08:26 -0600
  2. Return-Path: <yackd@texas.et.byu.edu>
  3. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.2-13 #4169) id
  4.  <01H4J88LEPGG8WXAJ7@yvax.byu.edu>; Mon, 25 Oct 1993 15:06:25 MDT
  5. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.2-13 #4169) id
  6.  <01H4J88F2O288Y585L@yvax.byu.edu>; Mon, 25 Oct 1993 15:06:15 MDT
  7. Received: from yvax.byu.edu by alaska.et.byu.edu; Mon, 25 Oct 93 15:07:54 -0600
  8. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.2-13 #4169) id
  9.  <01H4J87MMFGW8WX8KB@yvax.byu.edu>; Mon, 25 Oct 1993 15:05:37 MDT
  10. Received: from texas.et.byu.edu by yvax.byu.edu (PMDF V4.2-13 #4169) id
  11.  <01H4J87EJ8Q88Y5AWZ@yvax.byu.edu>; Mon, 25 Oct 1993 15:05:25 MDT
  12. Received: by texas.et.byu.edu; Mon, 25 Oct 93 15:07:03 -0600
  13. Date: Mon, 25 Oct 1993 15:07:03 -0600
  14. From: yackd@texas.et.byu.edu (Don Yacktman)
  15. Subject: Re:  IMPORTANT: version 0.5 of license
  16. To: misckit@byu.edu
  17. Message-Id: <9310252107.AA25671@texas.et.byu.edu>
  18. Content-Transfer-Encoding: 7BIT
  19. Status: RO
  20.  
  21.  
  22. > Current authors should be
  23. > particularly concerned, as the proposed changes would affect
  24. > contributions made before this version of the license was
  25. > proposed.
  26.  
  27. Yes, please look at the license, make comments, and be aware of
  28. this fact.  But, ALSO, be aware that version 0.5, the one I just
  29. put up, is nothing more than a PROPOSAL and is not in effect for
  30. any software, so the current MiscKit remains under the LICENSE
  31. found in it's distribution.  That's another reason I did not
  32. re-release the kit itself with this license; some of the changes
  33. are dramatic, and I won't make them without folks' agreement
  34. on them.
  35.  
  36. As a side note, Chris has sent me a version of the LICENSE that
  37. he has edited, call it 0.5a, which I am evaluating, and may
  38. very well become version 0.6 tonight.  Since these changes
  39. are very dramatic, you might wish to hold off on comments
  40. until I put 0.6 out tonight, which I promise I will do.  Just
  41. the same, this issue needs to be resolved as completely as
  42. possible this week, as I do not wish to drag it out any
  43. longer, and I don't think anyone on the list wants to hear
  44. about it any more.  If you don't provide feedback, I am assuming
  45. that you approve without any reservations, so if anything at
  46. all bothers you about the license, it is imperative that you
  47. say so.  You will note that the changes in each iteration
  48. really do echo what is brough up here; I am trying to
  49. accomodate as many people as possible.  (I realize that to a
  50. certain degree this is impossible, but I am attempting to make
  51. the set of those who approve be as large as possible.)
  52.  
  53. So, do look at 0.5, make comments on it, and, even more important,
  54. look at 0.6 that will come out tonight and comment on that!
  55.  
  56. Finally, the biggest problem in here is guaranteeing that an
  57. author cannot remove a contribution.  Note that the most they
  58. can do is stop sending in enhancements; in which case the
  59. object will then have branched in versions, with the MiscKit
  60. version being a separate branch from whatever the author has.
  61. If we can't guarantee this legally, then the MiscKit objects
  62. will never be used:  Most people won't use an object that
  63. could disappear out from under them at any time, especially
  64. since most MiscKit objects could be written rather quickly by
  65. an individual.  If this cannot be resolved, we might as well
  66. require that the author transfer copyright and ALL rights to
  67. the MiscKit, which will dampen submissions, but at least allow
  68. the code to be re-used without fear... and I'd prefer to have
  69. the author retain copyright and rights, for philosophical reasons.
  70. If anyone with legal experience could provide me with a good
  71. solution, I would really appreciate it.  To sum up:  If an
  72. author can remove a submission in the future, then the MiscKit
  73. is pointless, and we should just close up shop now.  Not a
  74. pleasant thought at all.
  75.  
  76. Enough babble.
  77.  
  78. -don